Digital signal processing refers to the electronic processing of signals, or any application that involves rapid numeric processing. The software development for applications on digital signal processors is an iterative process. A compiler translates source code into an assembly language source code. An assembler translates the assembly language source code files into machine language object files. Source files may contain instructions, assembly directives, and macro directives. A linker combines the object files into a single executable object module or program. As the linker creates the executable module, it performs symbolic relocation and resolves external references. The linker accepts object files created by the assembler as input. The linker also accepts archive or library members and output modules created previously. The objective of this development process is to produce an executable module that may be stored and executed on a device or processor.
Debugging tools are available to test processors and the linked, executable code. Application software development requires a level of simulation, observability and controllability of the software within the hardware system being developed. Tools for debugging software in a system context include simulators and emulators.
An emulator is a software development tool that allows software under development to be executed, controlled, and viewed in a real hardware environment. An emulator may be hardware, software or both. An emulator allows a user to perform software and hardware development, and to integrate the software and hardware with the target processor.
The most desirable form of emulator allows software development to occur in the real product hardware environment. To allow this form of emulation, the target processor provides an emulation interface that accesses its internal state. An emulation interface provides control and access to every memory location and register of the target processor, and extends the target processor architecture as an attached processor. The emulator can start or stop execution of the target processor program. When the target is stopped, the emulator has the capability to load, inspect, and modify all processor registers. Program data and program memory may be upgraded or downloaded.
Traditional emulation provides start and stop control of a target system, and the ability for the user to inspect the stopped system. There is an increasing need to interact with and diagnose the running system. As systems become more complex, it is difficult for a human user to monitor each system, every time it is tested. Testing occurs throughout the development and manufacturing cycle. A means of automating such interactions is desired. Such capability also has value to the product in the field. It allows configuration for a particular use, diagnosis for repair, or accumulation of operating information.
From the foregoing it may be appreciated that a need has arisen for exchanging data between processors while emulating software applications. This is provided by a new data exchange system that exchanges data between processors, is provided by a system that includes a host processor and a target processor, and is referred to as Real-Time Data exchange (RTDX™). Data is exchanged by forming a data pipeline between the target processor and the host processor. The data pipeline includes a data unit on the target processor, an emulator, and a device driver on the host processor. The data exchange system sends data through the data pipeline by transferring the data from a target memory on the target processor with the data unit to the emulator. The data exchange system transfers the data from the emulator to the first device driver. The data may be accessed by a client coupled to the host computer or a server on the host computer. The data exchange system also sends data back through the data pipeline by matching a request from the target processor to data from the host computer.
RTDX may include an enhanced emulator that allows a user to define and develop software in the environment of the target processor. The emulator reads inputs from a host PC and produces outputs to the PC as an assistant for the target processor, for the purpose of determining appropriate software and operations signals. The developer may interface additional host PC software to the emulator, to provide control and data signals to the target processor. The developer also may add software to the target processor that interacts with the emulator, for purposes of exchanging control and data information. Ultimately, when the target processors are supplied with the appropriate software resulting from the emulation operations, the target processor operates in the manner that is comparable to the rest of its system.
A more detailed description of current RTDX may be found in application Ser. No. 09/432,646 filed May 26, 2000 of Kuzemchak et al entitled “Debugger With Real-Time Data Exchange” and Ser. No. 09/738,241 filed Dec. 15, 2000 of Deao et al entitled “Data Exchange System and Method For Processors.” Another is application Ser. No. 09/887,504 filed Jun. 22, 2001 of Deao et al entitled “Multiprocessor Emulation Support Using Dynamic Linking”. These applications are incorporated herein by reference.
In the current RTDX when a user wants to use RTDX in their DSP application they have to embed code. They have to declare themselves channels and have to make calls into RTDX API in order to send data on those channels up to the host and receive data from the host. The steps are as illustrated in FIG. 1 where it is necessary to add RTDX calls to the target application, compile the target application, link the target application and then load the target application before the target application can be run. Then the host application has to be created or modified and the host application needs to be run. The data is then analyzed or visualized. This has to be done each time there is a change or add an RTDX setup. The target application is always compiled the first time but currently each time something goes wrong and the user wants to use RTDX to de-bug the applications the above adding calls to the target application, compiling, linking and loading the target application steps are performed. The RTDX calls would be for example RTDX_CreateOutputChannel (designating the channel) and RTDX_write (giving channel, &-data and size of data).
It is desirable to shorten the debug cycle by eliminating edit, compile and relink/reload of target application.
It may also be desirable to provide an RTDX using a non-JTAG interconnect.